Problem

Under sustained load a fraction of mining shares were rejected as
BAD,Incorrect result even when the nonce was mathematically
correct. Miners see a rejection rate of roughly 0.3 % for no
apparent reason. Reproduced against this repo verbatim at ~0.17 %.

Root cause

receiveData in src/mining.js attached a one-shot 'data'
listener and resolved with whatever single chunk Node.js delivered:

const receiveData = (conn) => new Promise((resolve) => {
    conn.on("data", function listener(data) {
        conn.removeListener("data", listener);
        resolve(data.trim());
    });
});

TCP does not preserve application-level message boundaries. Under
event-loop pressure a single client message can span two 'data'
events, or two messages can arrive in one event. The one-shot
pattern has no way to recover: answer[0] ends up parsing a
fragment of a different message ("JOB", a mining_key suffix,
etc), parseInt(...) returns NaN, and miner_res !== random
triggers BAD,Incorrect result on a perfectly valid share.

The same fragmentation risk exists in connectionHandler.js
mainListener for the very first JOB_REQ on a new connection —
a truncated mining_key can be passed to miningHandler and
propagated into minersStats.pw for the rest of the session.

Fix

Install a single persistent 'data' listener per connection that
appends incoming chunks to a per-connection buffer, then hands out
one message per receiveData call.

Framing is dual-mode for backward compatibility:

• Fast path — if \n is in the buffer, cut there. Clients
  that terminate their messages get robust boundary detection.
• Legacy path — if no \n arrives within
  LEGACY_IDLE_FLUSH_MS (10 ms) after the last chunk, treat the
  buffer as a single message. TCP fragment parts of the same
  logical message arrive sub-ms apart at receive side, so this
  idle gap cleanly separates "still arriving" from "message
  complete".

Existing miners that do not append \n (AVR_Miner.py,
PC_Miner.py, and most community clients) are unaffected — they
hit the legacy path with an imperceptible 10 ms tail. New clients
that opt in to \n termination get the zero-latency fast path.

Validation

Test harness: 47 concurrent virtual-worker TCP sockets against the
patched pool, diff = 10, ~0.5 shares/sec/worker.

Evidence on the unpatched side included 30 distinct reject cycles
where the client's submitted nonce was the correct answer to the
pool's own (lastBlockhash, newHash) challenge (verified by
client-side SHA-1 comparison), but the pool's answer[0] parsed
as "JOB" or "...destroyer" (the mining_key tail) — proof that
the fragment-reassembly assumption was wrong.

Files changed

• src/mining.js — receiveData rewritten with persistent
  per-connection buffer + dual-mode framing.
• src/connectionHandler.js — mainListener refactored to the
  same pattern so the first JOB_REQ gets the same protection;
  post-\n leftover is handed off to mining.js via the shared
  conn._recvBuf so no bytes are lost at the handler boundary.

No client-side changes required. No API changes. No configuration
changes.